Uniform access to entities in registered data store services

ABSTRACT

An enterprise system may separate the executable functionality existing in backend applications, and the separation may be at differing levels of granularity. The separated functions of the application may be registered in a catalog in the form of metadata objects. Once the executable functionality has been registered, the authorization information for each granular functional object may be associated with authorization information. In this manner, the authorization of a service of an application may be made on a feature by feature (or object by object) basis in a unified manner.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims priority to and is a Continuation-In-Partapplication under 35 U.S.C. §120 of U.S. patent application Ser. No.11/191,771, filed Jul. 28, 2005, which is a Continuation-In-Partapplication under 35 U.S.C. §120 of U.S. application Ser. No.11/165,748, filed Jun. 23, 2005, which are both incorporated byreference herein.

BACKGROUND

Organizations may use many applications, such as general purpose datacentric applications using persistent data, within a computingenvironment to carry out daily operations. For example, multiple typesof line of business (LOB) systems (e.g., business critical databaseapplication) may be implemented along with development applications,‘home-grown’ applications, and the like. However, access to each ofthese heterogeneous applications by one or more users may requireinteractions with different information, in different formats, indifferent languages and/or semantics, with different log-on andauthorization methods, with different connection requirements, withseparate operational threads for each user on each application, and thelike.

SUMMARY

The following presents a simplified summary of the disclosure in orderto provide a basic understanding to the reader. This summary is not anextensive overview of the disclosure and it does not identifykey/critical elements of the invention or delineate the scope of theinvention. Its sole purpose is to present some concepts disclosed hereinin a simplified form as a prelude to the more detailed description thatis presented later.

To unify the user's experience with the multiple applications, a datastore service system may be implemented which acts as an intermediarybetween the user and the multiple applications to provide a simple andunified interface for the user and to generate the complex and specificinteractions with the individual services of the multiple applicationsavailable for access. The parent application, U.S. patent applicationSer. No. 11/191,771, filed Jul. 28, 2005, describes a data store servicesystem which exposes disparate or heterogeneous data store relatedservices to the user without requiring the user to have applicationspecific knowledge of how to interact with the specified service. Toprovide the unified interaction to the user, the data store system maymaintain with a metadata store information such as service interactiondetails, e.g., available services, description of services, data types,how to access specific data, how to communicate semantically with aservice to access the desired data, and the like. The data store servicesystem may provide an application program interface which receives auser request for access to a service, access the associated metadata,and using the metadata, convert the user's simple, universal, unifiedand/or common request to a communication appropriate for the service.

Generally, to allow prefabrication and pooling of connections to anapplication and avoid pass through of individual user information, anapplication may be accessed within the context of a ‘super-user’, e.g.,an account that has access to all available data which may be forperformance reasons. In this manner, one or more (e.g., x) ‘super-user’connections may be held open simultaneously (which may be done inadvance to actual user log-on) to service one or more (x) unique endusers simultaneously with the x connections without requiring closureand re-establishment of the connection for each user request. However,implementing a super-user account is in conflict with individualsecurity. Specifically, if all data is accessed effectively anonymously,e.g., all requests to the application come from the ‘super-user’account, then it is not possible to trim which user accesses which databased on personal permissions. To reduce this problem, many applicationsprovide their own authorization modules which allow administrators tospecify who has access to what data stored in the system. However, thisrequires talking to the application as a specific end user, and not asuper-user. This solution precludes the performance gains achieved by asuper-user account. For example, the communications of authorizationinformation for each user may need to be secured and the authorizationrequest pass-through increases the amount and time of communication withthe service. In addition, since each requesting user is individuallyauthorized, each request for a service may run on a separate processingthread, which may over-burden a service and the available communicationconnections. Also, each application has its own model, which requiresseparate authorization for each different application for each user,requiring multiple sets of credentials and/or accounts to be set up andmaintained for each user, which increases the personal andadministrative management of the environment. Moreover, each applicationor service may expose a particular granularity to the information. Forexample, a SQL application may only expose access to information at thetable level, but not at higher or lower levels (described furtherbelow). Similarly, access for services of some applications may beprovided in a global sense, e.g., any right is a global right to accessany part of the services of the application. This may limit thegranularity of access allowed for an identified user.

As a result of the scalable account access and security goals, prior artapplication environments may ‘turn off’ the individual application'ssecurity model, and write custom code ‘in front’ of the application.This home-grown code may be responsible for cataloging the data in thespecific application and mapping out the permissions for each user. Inthis manner, end users may interact with the intermediate layer whichchecks permissions, and if permissions are available, the custom codeimpersonates the super-user and calls the application service andforwards the data retrieved back to the end user. Although this achievesscalability and security, it is at the expense of custom coding, whichis created by hand, at the intermediate layer for each back end system.Moreover, the custom coding must be accomplished individually for eachdifferent back-end application, despite similarities in desireindividual permissions, and the like.

The custom coding requires intimate knowledge of the data stored in theback end system and of the APIs to be used to make calls against thesystem. For example, each application may have its own uniqueauthorization model and store its permissions granted to users in itsown way. Moreover, each application may identify its sets of users in adifferent manner. For example, a system based on Microsoft's ActiveDirectory may identify a person as Redmond/person and another systembased on open source LDAP Directory may identify the same person asO=Redmond;CN=person. Thus, there may be no way to tell that these usersare the same user. Administrators must then learn various authorizationmodels and permissions which are scattered across many applications.Additionally, authorization of each user must be repeated for everyapplication accessed by the user, since each application may have itsown authorization technique and or credentials. In this manner, thecustom coding required may increase maintenance of the software, cost,time to market, and the like.

Since the data store service system of the parent application accessesthe service as a middle tier, authorization of a requesting user may bedifficult due to the maintenance cost, time to market, etc. of thecustom code cataloging the data services of each back-end applicationand mapping the user permission. To extend the unified interaction forthe user, reduce the user's need for understanding the details of thesemantics of an underlying application, expose a user definedgranularity to the services of an application, reduce administrationcosts, and/or for any other advantage, the data store service system mayauthorize a user based upon the services requested by the user andauthorization information associated with the requesting user. Theauthorization information may be stored in the metadata data store, suchas by associating a requested service, data type served up by a service,individual methods on a data type of a service, specific sub-componentsof the return values of a method of a data type of a server, objectinstantiation of any of the above, and the like with a user identifierof an authorized user and/or with one or more rights or allowed actionsof the authorized user. A separate (higher privilege) right may be usedto control the set of people that can set/change rights (similar to anadministered right) on any object. In some cases, security features of aparent object may be propagated down to child objects automatically,upon request, or in any other determined manner. The security featuresmay be surfaced by injecting access check calls for various rights atkey methods on the securable objects. If the user is authorized, thedata store service system may access the service through a singlesuper-user account using data store service system authorizationcredentials through the service in accordance with the determinedauthorization and allowed rights.

Many of the attendant features will be more readily appreciated as thesame becomes better understood by reference to the following detaileddescription considered in connection with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the followingdetailed description read in light of the accompanying drawings,wherein:

FIG. 1 is a schematic diagram of an example enterprise environmentsuitable for implementing a data store service system;

FIG. 2 is a table of an example metadata store suitable for use with theenterprise environment of FIG. 1;

FIG. 3 is a table of an example access control list (ACL) of themetadata store of FIG. 2);

FIG. 4 is a schematic diagram of a securable object hierarchy compatiblewith the enterprise environment of FIG. 1;

FIG. 5 is a schematic diagram of an example API for implementing anaccess control list of an object;

FIG. 6 is a schematic diagram of an example API for implementing anaccess control entry of an access control list of FIG. 5;

FIG. 7 is a flow chart of an example method of populating andimplementing a metadata store of the enterprise environment of FIG. 1;

FIG. 8 is a flow chart of an example method of conducting an accesscheck;

FIG. 9 is an example display of an administration user interface of anobject;

FIG. 10 is an example display of a manage permission user interface ofan object;

FIG. 11 is an example display of an ACL editing user interface;

FIG. 12 is an example display of an object editing user interface;

FIG. 13 is an example display of a modify permission user interface; and

FIG. 14 is a flow chart of an example method of executing a metadatastore of the enterprise environment of FIG. 1.

Like reference numerals are used to designate like parts in theaccompanying drawings.

DETAILED DESCRIPTION

The detailed description provided below in connection with the appendeddrawings is intended as a description of the present examples and is notintended to represent the only forms in which the present example may beconstructed or utilized. The description sets forth the functions of theexample and the sequence of steps for constructing and operating theexample. However, the same or equivalent functions and sequences may beaccomplished by different examples.

Although the present examples are described and illustrated herein asbeing implemented in a enterprise environment with multiple line ofbusiness applications accessible through a network connection, theenterprise environment described is provided as an example and not alimitation and it is to be appreciated that any number and types ofservices may be provided in any number and/or combination of thefeatures described further below.

FIG. 1 and the following discussion are intended to provide a brief,general description of a data store service system within an enterpriseenvironment. As shown in FIG. 1, one or more user devices 120 mayconnect to the enterprise system 130 through a network 133, representedby a cloud, may be directly connected to the enterprise system through aconnection 135, may be a part of the enterprise system, or access theenterprise system in any suitable manner.

Network 133 may include many well-known components, such as routers,gateways, hubs, and the like and allows the user device 120 tocommunicate via wired and/or wireless media. Network 133 may comprise aWide Area Network (WAN), such as the Internet, a local area network(LAN), although a variety of other communication systems and/or methodsusing appropriate protocols may be used, including other types of WANs,LANs, wireless networks, phone lines, serial and/or parallel cables,coaxial cables, and any combination thereof.

Each user device 120 may provide a suitable computing environment toprovide access to services available from the enterprise system 130.User device 120 and the enterprise system 130 of FIG. 1 and thefollowing discussion are intended to provide a brief, generaldescription of a suitable computing environment in which all or aportion of a data store service system may be implemented.

The operating environment of the user device 120 and the enterprisesystem 130 of FIG. 1 are only one example of a suitable operatingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the operating environment. Other wellknown computing systems, environments, and/or configurations that may besuitable for use with a user interface editing application describedherein include, but are not limited to, personal computers, servercomputers, hand-held or laptop devices, multiprocessor systems,micro-processor based systems, programmable consumer electronics,network personal computers, mini computers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

With reference to FIG. 1, an exemplary system for implementing useraccess to the enterprise system 130 includes a computing device, such asuser computing device 120. In its most basic configuration, computingdevice 120 typically includes at least one processing unit 102 andmemory 104. Depending on the exact configuration and type of computingdevice, memory 104 may be volatile (such as RAM), non-volatile (such asROM, flash memory, etc.) or some combination of the two. This most basicconfiguration is illustrated in FIG. 1 by line 106. Additionally, device120 may also have additional features and/or functionality. For example,device 120 may also include additional storage (e.g., removable and/ornon-removable) including, but not limited to, magnetic or optical disksor tape. Such additional storage is illustrated in FIG. 1 by removablestorage 108 and non-removable storage 110. Computer storage mediaincludes volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules, orother data. Memory 104, removable storage 108, and non-removable storage110 are all examples of computer storage media. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVDs) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bydevice 120. Any such computer storage media may be part of device 120.

Device 120 may also contain communication connection(s) 112 that allowthe device 120 to communicate with other devices, such as with othercomputing devices through network 133. Communications connection(s) 112is an example of communication media. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term ‘modulated data signal’ means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, radiofrequency, infrared, and other wireless media. The term computerreadable media as used herein includes both storage media andcommunication media.

Device 120 may also have input device(s) 114 such as keyboard, mouse,pen, voice input device, touch input device, laser range finder,infra-red cameras, video input devices, and/or any other input device.Output device(s) 116 such as one or more displays, speakers, printers,and/or any other output device may also be included.

In one example, the user device may use communication connection 112 toaccess the enterprise system 130 through the network 133 to request oneor more services of the multiple enterprise applications 150 supportedby the enterprise system. To support the multiple enterpriseapplications 150, the enterprise system 130 may be a computing devicesimilar to or different from that described above with reference to theuser device 120.

As shown in FIG. 1, the enterprise system 130 may provide a suitablecomputing environment to provide the services available from theenterprise applications 150. Although not required, the data storeservice system 160 and other components of the enterprise system will bedescribed in the general context of computer-executable instructions,such as program modules, being executed by one or more computers orother devices. Generally, program modules include routines, programs,objects, components, data structures, etc., that perform particulartasks or implement particular abstract data types. Typically, thefunctionality of the program modules may be combined or distributed asdesired in various environments.

With reference to FIG. 1, an exemplary system for providing the servicesfrom the enterprise applications 150 of the enterprise system 130includes a computing device, such as computing device 130. In its mostbasic configuration, computing device 130 typically includes at leastone processing unit 132 and memory 134. Depending on the exactconfiguration and type of computing device, memory 134 may be volatile(such as RAM), non-volatile (such as ROM, flash memory, etc.) or somecombination of the two. This most basic configuration is illustrated inFIG. 1 by line 136. Additionally, device 130 may also have additionalfeatures and/or functionality. For example, device 130 may also includeadditional storage (e.g., removable and/or non-removable) including, butnot limited to, magnetic or optical disks or tape. Such additionalstorage is illustrated in FIG. 1 by storage 138. Device 130 may alsocontain communication connection(s) 142 that allow the device 130 tocommunicate with other devices, such as with other computing devicesthrough network 133.

Device 130 may also have input device(s) 144 such as keyboard, mouse,pen, voice input device, touch input device, laser range finder,infra-red cameras, video input devices, and/or any other input device.Output device(s) 146 such as one or more displays, speakers, printers,and/or any other output device may also be included.

Those skilled in the art will realize that storage devices utilized tostore program instructions can be distributed across a network. Forexample a remote computer may store an example of the process describedas software. A local or terminal computer may access the remotecomputer, which may be through the enterprise system 103, and download apart or all of the software to run the program. Alternatively, the localcomputer may download pieces of the software as needed, ordistributively process by executing some software instructions at thelocal terminal and some at the remote computer (or computer network).Those skilled in the art will also realize that by utilizingconventional techniques known to those skilled in the art that all, or aportion of the software instructions may be carried out by a dedicatedcircuit, such as a DSP, programmable logic array, or the like.

A user device 120 may interact with the enterprise system 130 to accessone or more services of the multiple applications 150, which may residein memory 134, in storage 138, or may be remotely accessed by theenterprise system 130 such as through a communication connection.Although FIG. 1 illustrates the service applications 150 as resident inthe memory 150 of the enterprise system 130, it is to be appreciatedthat one or more of the applications 150 may reside in separate memoriesand/or separate computing devices which may be accessible through aconnection such as through a communication connection.

The applications 150 may provide any suitable services to the userdevice 120. Example applications may include enterprise applicationssuch as line of business systems such as those provided by SAP orSIEBEL. Other examples may include ‘home-grown’ applications of theenterprise, Internet services such as World Wide Web sites, and thelike.

The interaction with the enterprise system may be through a portal 170,shown in FIG. 1. The portal may act as an entryway into the enterprisesystem, and/or may facilitate interactions with the enterprise system.One example of a suitable portal may include the SharePoint System™available from Microsoft Corp. of Redmond, Wash. In response to userrequests through the portal 170, the processor 132 may access and/orexecute one or more applications 150 to allow a user device 120 toaccess data or execute methods which may be stored in the enterprisesystem, such as in memory 134 or storage 138 or remotely accessed by thedata store service system 160.

A user device 120 may directly execute the desired application to accessa desired service. However, as shown in FIG. 1, the enterprise system130 may provide a data store service system 160 as an interface betweena user device 120 and the one or more applications 150. In this manner,the data store service system may unify the user's experience with themultiple applications 150 by acting as an intermediary between the userand the multiple applications to provide a simple and unified interfacefor the user and to generate the complex and specific interactions withthe individual services of the multiple applications available foraccess.

Any suitable data store service system 160 may be provided. One suitabledata store service system is described further in U.S. patent Ser. No.11/191,771 filed Jul. 28, 2005, and is described briefly here forclarity. To provide the unified interaction to the user, the data storeservice system 160 may include a service system module 190 to maintainservice interaction details with a metadata store 180. The data storeservice system 160 may provide an application program interface whichreceives a user request 162 for access to a service, accesses theassociated metadata store 180, and using the metadata, converts theuser's simple (and possibly unified) request 162 to a communication 164appropriate for the specific requested service of the applications 150.

The metadata store 180 may provide an indication of availableapplications, available services, description of services, data types,how to access specific data, how to communicate semantically with aservice to access the desired data, and the like.

The available applications, services, data, and the like may berepresented as objects of a particular type. For example, a request toaccess a system object may represent a request to access the applicationassociated in the metadata store. The application, such as one ofapplications 150 may be represented as a collection of computationallogic that is implemented using persistent and/or transient data. Inanother example, a request to access an entity object may represent arequest to access a collection of related fields or data and method orlogic definitions, which may be through services of one or more of theapplications 150. In another example, a request to access a methodobject may represent a request to access data associated with anapplication program interface, or any other suitable methods. In anotherexample, a request to access a parameter may represent a request toaccess a single field or data which is associated with a method orsystem. In another example, a request to access a type descriptor objectmay represent a request to access all data of a particular type, such asall data of a particular type or column in column delimited informationassociated with a particular system.

One example of a metadata store 180 is shown in the table 200 of FIG. 2.In the metadata store, an object indicator representing availableservices to a user may be associated with identifying information andany other information which may be used by the service system module 190to convert the unified simple request 162 from the user to a complexcall 164 in the format required by the application 150.

As shown in FIG. 2, the metadata store 180 may associate a systemidentifier 202 with one or more of a system descriptor 206, and/or anyother suitable information. The system identifier 202 may be anysuitable identifier of the desired system. A system may be an entireapplication of the applications 150, or may be a particular service orfunction of the one or more applications 150. The system descriptor 206may be any suitable description of the type and/or general function,purpose or name of the associated application in the applications 150.For example, the system identifier may be a unique identifier associatedwith a system descriptor identifying a type of LOB or other application,such as SAP, Siebel, and the like.

As shown in the FIG. 2, the metadata store 180 may associate a systeminstance identifier 203 with one or more of connection information 204,a system identifier 202, and any other suitable information. A systemidentified by the system identifier may be instantiated when theconnection information 204 is associated with the system instantiationidentifier 203 and the system identifier 202. It is to be appreciatedthat a single system, e.g., SAP identified by a single systemidentifier, may have multiple instances across the enterprise system,e.g., multiple versions accessible through different connection or thesame system accessible through different connections. In this manner,each system identifier may be associated with zero or more systeminstantiation identifiers. The connection information 204 may be anysuitable connection information which allows the data store servicesystem to communicate and/or interact with the associated systeminstance such as network location, host server name, port number, datastore service system credentials, information regarding how to connectto the system, and the like. The data store service system credentialsmay include authentication and/or authorization for the data storeservice system to access the associated system. As used herein,authentication means identification of the requesting device or user andauthorization means verifying that the requesting user or device haspermission or rights to access the requested service. An indication ordescription of the instantiation may be included in the connectioninformation and/or the system descriptor.

As shown in the table 200 of FIG. 2, the metadata store 180 mayassociate an entity identifier 212 with one or more of an entity typedescriptor 216, a system identifier 202, and the like. The entityidentifier 212 may be any suitable identifier which indicates aparticular collection of related fields or data and/or method or logicdefinitions available in the associated system identified by the systemidentifier 202. In this manner, each system identifier 202 may beassociated with zero or more entity identifiers 212. For example, an SAPsystem may have one or more associated entity identifiers indicatingcustomer entities, order entities, product entities, and the like. Themethod identifier may be any suitable identifier indicating a set oflogic or instructions of a system which may be executed to retrieve thedesired data. The entity type descriptor 216 may be any suitableindication of the data or fields of data which will be retrieved if theassociated method is executed. An instance of an entity is an actual setof values for each field in the entity definition, which may be obtainedby executing one of the methods defined in the entity object.

As shown in the table 200 of FIG. 2, the metadata store 180 mayassociate a method identifier 222 with one or more of an entityidentifier 212, a parameter list 226, and the like. In this manner,metadata about a system's application program interface may be called amethod. The entity identifier 212 may represent the associated entitythat may use the identified method to retrieve particular information.In this manner, each entity identifier 212 may be associated with zeroor more method identifiers 222. The method identifier 222 may be anysuitable identifier indicating a set of logic or instructions which maybe executed as part of one of the applications 150 to access and/ormanipulate the indicated entity. The method identifier may indicate thetype of method, such as read, write, update, delete, and the like. Forexample, a customer entity in an SAP system may provide one or more of acreate customer method, a view customer method, and the like. Theparameter list 216 may be any suitable parameter list in any suitableformat that indicates the parameters and/or their required structuresand/or formats that may be needed to invoke the identified method. Forexample, the parameter list may include one or more identifiers ofparameter objects and/or definitions of format and type of parameterrequired. However, it is to be appreciated that the parameter objectitself may provide a definition of the format and/or type of parameterrequired.

A single system API may be used with different semantics within theenterprise system. For example, the same API can be used to find manyinstances of an entity (such as by using wildcard as an input) as wellas to find a specific instance of an entity. To conserve cache spacewithin the metadata store, the concept of a method instance may beintroduced as a representation of an association between a method and aset of default values for each of the parameters of a method. Thus,invoking two method instances that are associated with the same methodmay yield two entirely different results.

As shown in table 200 of FIG. 2, the metadata store 180 may associate aparameter identifier 232 with one or more of a parameter descriptor 234,a method identifier 222, and the like. The method identifier 222 mayindicate the one or more method identifiers which may use that parameterobject during invocation of the method. In this manner, each methodidentifier 222 may be associated with zero or more parameter identifiers232. The parameter identifier 232 may be any suitable identifieridentifying the associated parameter. The parameter descriptor 234 maybe any suitable information describing the associated parameter, such asan indication of a parameter type (e.g., string, integer, real, and thelike), parameter format, and the like.

As shown in table 200 of FIG. 2, the metadata store 180 may associate aparameter type identifier 242 with one or more of a tag 244, a parameteridentifier 232, a default value 248, and the like. The parameter typeidentifier 242 may be any suitable identifier identifying the associatedparameter type. In one example, the parameter type identifier mayindicate the type of value that the parameter may take, such as string,integer, real, and the like. In another example, the parameter typeindicator may indicate the type of data associated with the parametervalue, such as cost, individual's name, product code, contactinformation, and the like. It is to be appreciated that any suitable setof parameter types may be used in accordance with the environment andapplications. For example, one or more parameter type identifiers 242may be associated with another parameter type identifier 242 and/or maybe associated with a single parameter identifier 232. In this manner, aparameter type identifier 242 and its associated data may represent afiled on a complex parameter. The tag 244 may be any suitable indicatorof a type or other characteristic of the parameter type, such a whetherthe associated parameter type is an identifier, a filter, and the like.The parameter identifier 246 may indicate the parameter identifiers,e.g., one or more of parameter identifier(s) 232, having that parametertype. The default value 248 may be any suitable default or null valueindicating a default value of the parameter associated with theparameter type if no value is stored or indicated. For example, thedefault value may be a strict value, and/or may indicate the format ofthe value of the parameter.

Although FIG. 2 illustrates the metadata store 180 of FIG. 1 as a singletable 200, it is to be appreciated that any suitable data store in anysuitable format may be used to store and/or communicate the metadatastore, and the like, including one or more of a relational database,object-oriented database, unstructured database, an in-memory database,or other data store. A storage array may be constructed using a flatfile system such as ASCII text, a binary file, data transmitted across acommunication network, or any other file system. Notwithstanding thesepossible implementations of the foregoing data stores, the term datastore and storage array as used herein refer to any data that iscollected and stored in any manner accessible by a computing device.

It should be appreciated that the entry items and manner in which table200 is organized in FIG. 2 are provided for ease of illustration anddescriptive purposes only, as the particular data items provided and themanner they are organized may vary depending on the particularenvironment and language in which they are employed. In one example, themetadata store may be implemented as an XML file containing serializedmetadata object definitions. Each application may have one or moresystems, with each system containing one or more other hierarchicalobjects, e.g., entity, method, parameter, parameter type, and the like.

By populating the metadata store 180, one or more applications 150 maybe registered with the enterprise system 130, e.g., a system object maybe instantiated within the metadata store and associated with one ormore lower hierarchical objects as appropriate, such as entities,methods, parameters, and the like. In this manner, a user may providethe service system module 190 of FIG. 1 a simple request (e.g., request162) for access to a service. By referencing the objects and theirassociated metadata in the metadata store 180, the service system module190 may convert the unified request 162 into a complex and applicationspecific request 164 in the appropriate format without the user beingrequired to have detailed knowledge of the format, language, andsemantics of individual and often heterogeneous applications providingavailable services to users.

Since the data store service system 160 may convert user requests 162into formatted and semantically correct requests 164 and interacts withthe applications 150, the applications 150 may authenticate and/orauthorize the data store service system, such as through the data storeservice system credentials of the connection information 204 stored inthe metadata store 180. However, even if the data store service system160 is authenticated and authorized, this does not mean that therequesting user 120 is also authorized to access the service. As notedabove, transmitting the user's identity and individual credentialsthrough to the application may have drawbacks. Moreover, maintaining auser's identity in a multi-tier system across multiple computers can betechnically challenging. Thus, the service system 160 may determine theappropriate authorization of the requesting user, before accessing theservices of the associated application 150. In this manner, a unifiedinteraction for user authorization may be provided across multipleheterogeneous applications, which may reduce the need to manage multipleuser accounts for each application, and to manage multiple usercredentials for each user for each application.

To authorize a user's access to a requested service, the data storeservice system 160 may provide an authorization module (not shown) orthe authorization services may be a part of the functions of the servicesystem module 190, as shown in FIG. 1. More particularly, the servicesystem module may verify that the identified user device has theappropriate rights to the requested service. The authorizationinformation may be stored in the metadata data store 180, such as byassociating an object identifier of a service with one or more of useridentifiers and/or with one or more rights or allowed actions of theauthorized user.

As shown in the table 200 of FIG. 2, the metadata data store 180 mayassociate an object identifier (such as system identifier 202, entityidentifier 212, method identifier 222, parameter identifier 232,parameter type identifier 242, and the like) with one or more of a useridentifier 250, one or more rights 252 or allowed actions of theidentified user, and the like. The user identifiers 250 may list alluser identifiers or only those user identifiers having associated rightsin the associated service. If the user identifiers include only thoseuser identifiers having positive rights (e.g., rights to access aservice of the object), the user identifier 250 and associated rights252 may be referred to as an access control list (ACL). In this manner,each securable object in the metadata store may have an associated ACLwith each ACL comprising one or more access control entries (ACEs) whichis a data structure or record of a user identifier with its associatedset of rights detailing what the associated user can do.

The user identifier may be any suitable user identifier such as usercontext descriptor indicating one or more of an individual, a group, adevice, a connection, role, software application, time of request,location of the user device, and the like. In a simple example, the useridentifier may be an individual's account with the portal 170. In a morecomplex example, the user identifier may be a combination of a useraccount with the portal through a specific connection (which may have arequired security level), within a specified range of time of day (e.g.,working hours). In this manner, access to services may be controlledwith a granularity that may be more fine-grained than that available byany one or more of the underlying back-end applications 150.

Each user identifier in the ACE may have an associated one or more rightindicators 252 which indicate the action(s), power(s), and/orprivilege(s) that are allowed by the indicated user. The right indicator252 may be any suitable indicator of rights associated with the object.For example, the rights associated with an object include one or more ofviewing the object (e.g., viewing data stored in a back end system thatis represented by the object which may be performed by executing theobject to get the data back), editing the object, enabling or disablingfeatures of the object, setting permissions of the object (e.g., modifythe associated ACL), executing the object (e.g., if the object is amethod), showing a copy of the object, and the like. In some cases, thelack of a positive right listed in the ACE may indicate that the rightis not provided to the indicated user identifier. In other cases,negative rights may be included in the ACE, such as NOT editing theobject. This latter example may be useful if an object has a default setof rights given to all users unless otherwise specified in an associatedACL.

It is to be appreciated that an object, such as a method and the like,may not have an associated ACL. The data store service system 160 mayinterpret the lack of an associated ACL in any suitable manner. Forexample, no ACL may indicate that all users may have all or apredetermined or default set of rights, which may be appropriate in thecase of a filter object. In another example, no associated ACL mayindicate the no users have any rights. However, it is to be appreciatedthat some default rights may be instantiated automatically for eachobject, such as the right to modify the object itself in the metadatastore.

An example ACL associated with a single object (e.g., system, entity,method, parameter, parameter type, and the like) is illustrated in thetable 300 of FIG. 3. The ACL 300 contains a list of one or more ACEs302, 304, 306. Each ACE may be represented by an ACE identifier whichidentifies the associated ACE. In one example, the ACE identifier may bethe ACE itself, i.e., the list of authorized user identifiers and theassociated rights for each associated user identifier. As shown in FIG.3, the ACE identifier may be an identifier indicating a data structurestoring the associated ACE list of user identifier(s) and rights. Forexample, ACE 302 may indicate the data structure 320 which contains theuser identifiers 322, 324 and their associated rights identifiers 326,328. In a similar manner, the ACE 306 may indicate the data structure360 which contains the user identifiers 362, 364 and their associatedright identifiers 366, 368. To simplify finding the correct ACEassociated with a requesting user, the ACE identifier 302, 304, 306 mayinclude at least a portion of the user identifier or some other userindicator that may be received from or discovered about the requestinguser.

It is to be appreciated that one or more objects may share the same ACLand/or one or more ACLs may share the same ACEs. In this manner, globalrights of a user may be tailored to individual services with multipleACLs and/or ACEs, or collectively changed for all services with multipleACLs referring to a single ACE.

When an object is instantiated in the metadata store, the service systemmodule 190 may determine a default security setting for the object. Thedefault security setting may be the same or different for differenttypes of objects. For example, a new system object may have an open (orno) security setting, meaning that unless otherwise indicated in an ACL,that all users will have all rights. However, entities, and methodinstances associated with the system may have a closed security setting,meaning that unless otherwise indicated in an ACL, no users will haverights in the object. It is to be appreciated that any default securitysetting may be used as appropriate.

In some cases, an object may have a default security setting derivedfrom a parent object to provide or deny access to the service orresource associated with the object. For example, as noted above, theobject hierarchy may include any combination of a system, entity,method, parameter, parameter type, and any other suitable object type.Thus, an instantiated entity object may inherit the security or ACL fromits parent system object. In one example, the security settings (e.g.,ACL) may be inherited only from a direct parent. In another example, theACL may be inherited from one or more of any ancestors (parents,grandparents, etc.) of the object. For example, a lower hierarchicalobject, such as a parameter may inherit the ACL only from its parentobject, e.g., the associated method object. The method object may haveits own ACL, or may refer to its own parent's ACL, e.g., the entityobject. In another example, a lower hierarchical object, such as aparameter may inherit the ACL from any or all of its ancestral objects.More specifically, a lower hierarchical object may inherit the ACL fromits parent, e.g., the method object, and may combine it with the ACLfrom the grandparent, e.g., the entity object, and may further combineit with the ACL from the great-grand-parent, e.g., the system object.The combination of multiple ACLs from ancestral objects may be anysuitable combination such as a union of all ACEs contained in thecombined ACLs, a merge which removes duplicated ACEs, and anintersection of the ACLs which selects the minimal amount of users andrights that are consistent with all combined ACLs, and the like.

In some cases, an additional or alternative hierarchy may be provided toallow inheritance of security settings, such as ACLs and/or ACEs, toprovide or deny access to a service or resource associated with theobject. For example, a security hierarchy may be created which allowsACLs and/or ACEs to be inherited outside of the object hierarchy orwithin the object hierarchy in a predetermined manner.

In one example, each secured object in the metadata store may not haveits own ACL associated with the object identifier. In some cases, anobject may borrow or refer to an ACL of another object. The ‘otherobject’ may be determined as the nearest metadata object that isimportant enough to have its own ACL. The nearest metadata object may bedefined in any suitable manner. For example, the nearest object may bedefined as the nearest ancestor (e.g., parent, grand-parent, and thelike) of the object as defined within the object hierarchy for aninstantiated system. In another example, the nearest object may bedefined as the nearest relative (e.g., parent, child, grand-parent, andthe like) of the object as defined within the object hierarchy for aninstantiated system. In another example, the nearest object may bedefined as another object in the metadata store which is most similar tothe object. For example, if the object is a parameter indicating thecustomer list in a SAP application, then the nearest object may be thecustomer parameter from a similar system, such as another SAPapplication or a SIEBEL application.

To implement a hierarchical and hereditary security from one object toanother, a security hierarchy may be generated. Any suitable hierarchymay be used. For example, FIG. 4 illustrates an example hierarchy 400 ofsecurity object classes that may be used to define inheritance. Inaddition to an unsecured object 406, the hierarchy 400 introduces twoabstract object classes, the access controlled metadata object 402 andthe individually controlled metadata object 404. The access controlledmetadata object may represent the class of objects that need accesscontrol, such as through an ACL, regardless of the source of the ACL.The individually controlled metadata object 404, which is itself anaccess controlled metadata object, supplies an ACL that it owns.

The metadata object 406 may be used to classify objects that require nosecurity or user authorization. One example of an object that may beclassified as a metadata object 406 may be a filter.

The access controlled metadata object 402, that is not an individuallycontrolled metadata object, does not own its own ACL, but rather,depends on an ACL from another object, such as an individuallycontrolled metadata object. In this manner, the access controlledmetadata object may use subclassers to implement a method that willprovide a link to the nearest ancestor that is individually securable(i.e., owns an ACL). One example of an object that may be classified asan access controlled metadata object may be an action object and/or aparameter object.

In one example, the access controlled metadata object may be implementedas an API. The access controlled metadata object 402 API may provide oneor more methods or functions. The methods may include a get accesscontrol list, which may retrieve the appropriate ACL from the nearestindividually securable ancestor. The access controlled metadata object402 may provide a method such as get nearest individually securableancestor which determines the owner of the desired ACL. As noted above,the nearest ancestor may be determined in any suitable manner. Forexample, the nearest ancestor may be the nearest relative (e.g., child,parent, grandparent, and the like) which is an individually securableobject or may be the nearest ancestor from a higher level of thehierarchy (e.g., parent, grandparent, and the like). Proximity to theaccess controlled metadata object may be determined in any suitablemanner, such as type of object or number of ‘generations’ or levels awayin the object type hierarchy (e.g., system, entity, method, parameter,parameter type, and the like).

The individually securable metadata object 404 owns its own ACL. Theindividually securable metadata object may return itself when asked forthe nearest individually securable ancestor, which may fulfill thedefinition for access controlled metadata objects. In turn, theindividually securable metadata object may put a requirement onsubclasses to supply all individually securable child objects of theindividually securable metadata object, such that the individuallysecurable object can copy or propagate its own ACL to its children ifnecessary. One example of an object that may be classified as anindividually securable metadata object may include a system object, anentity object, a method object, a method-instance object, and the like.

Similar to the access controlled metadata object, the individuallysecurable metadata object may be implemented as an API. The individuallysecurable metadata object 404 API may provide one or more methods orfunctions. Since the individually securable metadata object may be theaccess controlled object itself, the individually securable metadataobject may ‘inherit’ one or more of the functions or methods provided bythe access controlled metadata object, such as the get access controllist, get nearest individually securable ancestor, and the like. Theindividually securable metadata object may provide any other suitablefunctions and/or methods in addition to or alternative to the methodsinherited form the access controlled metadata object. For example, themethods may include a set access control list, which may allow a user topopulate and/or modify the access control list (and associated accesscontrol entries) owned by or associated with the individually securableobject. The individually securable metadata object 404 may provide amethod such as copy access control list to children, which may propagatethe access control list to the children of the object classified as theindividually securable metadata object. The propagation of the ACL mayaffect all children of the object, or may affect only a predeterminednumber of generations, a predetermined set of children (such as througha parameter list input, and the like).

To determine the children of the individually securable metadata object,the individually securable metadata object may provide a method to getthe children of the individually securable metadata object children. Thechildren of the object classified as the individually securable metadataobject may be determined in any suitable manner. For example, childrenmay be defined as those objects that depend from the object classifiedas the individually securable object as determined within an objecthierarchy (e.g., system, entity, method, parameter, and the like).

The factoring provided by the security hierarchy of FIG. 4 may allowobjects to subclass individually securable metadata object APIs whenaccess checks are required to be as fast as possible (without requiringwalking the object metadata tree (e.g., system containing entities,which contain methods, with contain parameters, etc.) since the ACL ison the individually securable metadata object itself. In some cases, anobject should not subclass the individually securable metadata object ifit is fine-grained since the storage associated with an ACL and the timeto propagate it may be significant. In addition, the access check may beable to tolerate the time taken to walk up the metadata object hierarchy(e.g., system containing entities, which contain methods, with containparameters, etc.) to find the nearest object with its own ACL.

The security classification of an object may be indicated in anysuitable manner. For example, the metadata store 180 may store asecurity type indicator indicating the classification of the object. Inanother example, the object identifier may indicate the classification.In another example, the object itself (e.g., code defining the object)may define and/or indicate the security classification.

In one example, the ACL and/or ACE may be implemented by the enterprisesystem using an application program interface. For example, each classor type of object may have an associated ACL API and/or ACE API. Theclass or type of object sharing an API may be related to the objecthierarchy (e.g., system, entity, method, parameter, and the like) and/ormay be related to the securable object hierarchy (e.g., object, accesscontrolled object, individually securable object, and the like). It isto be appreciated that the ACL and ACE APIs may be created in accordancewith any one or more individual or group features of the underlyingobjects. FIG. 5 illustrates a representation of an example ACL API 500and FIG. 6 illustrates a representation of an example ACE API 600. TheAPIs may have any suitable input, output, and/or function. For example,as shown in the example ACL API 500 of FIG. 5, the function of the APImay be to check access 502. More particularly, to check access, the ACLAPI 500 may verify that the requesting user is listed in an associatedACE and is associated with the appropriate rights. To check the access,the ACL API 500 may implement the ACE API 600 of FIG. 6.

The ACE API, when implemented may provide any one or more of thefunctions of set identity 606, get identity 608, set rights 602, getrights 604, and the like. The set identity 606 may be implemented tocreate and/or modify the user identifiers listed in the ACE. In thismanner, new user identities authorized for a particular object may besimply added or deleted by adding or deleting a row or record to theACE, or the entire or portions of the ACE may be replaced as a group.The get identity 608 may be implemented to view and/or verify the listof one or more user identifiers listed in the ACE. The set rights 602may be implemented to create and/or modify the rights of an associateduser listed in the ACE. In this manner, the rights function associatedwith a user identifier may be simply and/or centrally manipulated byadding or deleting rights as desired in the ACE of a particular object.The get rights function 604 may be implemented to view and/or verify thelist of one or more rights associated with a listed user identifier. Inthis manner, the check access function 502 of the ACL API 500 of FIG. 5may implement the get identity function 608 to verify that the user isauthorized in some manner. Specifically, the results of the get identityfunction may return a complete list of authorized users which may becompared to the user identity of the requesting user. In anotherexample, the requesting user's identifier may be provided to the ACEAPI, and when the get identity function is implemented, a verifier maybe returned that the indicated user identifier is included or excludedfrom the list of user identifier(s) in the ACE. In another example, therequested service or right of access may be provided to the ACE API, andthe get user function may return a list of user identifiers which havethe indicated right to access. The check access 502 of the ACL API 500may implement the get rights function 604 to verify that the identifieduser has the appropriate rights to access the service. In one example,the user identifier may be provided to the ACE API, and the associatedrights of that user may be returned and then compared to the requestedservice in the user request. In another example, the user identifier andthe requested service may be provided to the ACE API, and the get rightsfunction may return a verifier that the indicated right of access isauthorized or not authorized. It is to be appreciated that theauthorization of the user and associated requested right to access maybe verified in any suitable manner.

The ACL API 500 of FIG. 5 may include one or more indicators oridentifiers which describe the ACL API. For example, the ACL API mayinclude one or more of an ACL identifier 504, an ACL description whichmay be a description of the ACL or indicator of the object associatedwith the ACL, a cache indicator 508 which may indicate whether the ACLis cached in memory or must be retrieved from storage, and the like.

The ACE API 600 of FIG. 6 may include one or more indicators oridentifiers which describe the ACE API. For example, the ACE API mayinclude one or more of an ACE identifier 610, a metadata objectidentifier 612, a user identifier 614, a rights identifier 616, a systeminstance identifier 618, and the like. The ACE identifier 610 may be anysuitable identifier which identifies the ACE. The metadata objectidentifier 612 may be any suitable object identifier associated with theACE. For example, the metadata object identifier may include a referenceto the object such as a system object, an entity object and the like.The user identifier 614 may include the list of users who are authorizedto access the associated object under the rights indicated by the rightidentifier(s) 616. The system instance identifier 618 may be used insome cases to indicate a particular instance of a system object. Forexample, multiple instances of a system may be instantiated for a singlesecurable object like a method instance. For example, if thee are onehundred system instances of a product studio system (e.g., one ofapplications 150 of FIG. 1), the one or more method instance objects ofthe system can have separate ACLs for each system instance. The systeminstance identifier may be optional since it may be relevant for objectsthat are not systems or system instances.

FIG. 7 illustrates an example method 700 of creating and populating themetadata store 180 of FIG. 1. It is to be appreciated that anycombination and order of the below described operations may beimplemented as appropriate.

To set up the metadata store, a user, such as a developer, may requestto create 702 a metadata object. In response to the request to execute amethod (e.g., create an object), the service system module 190 of FIG. 1may determine 704 if the requesting user has access to the requestedmethod object. For example, the service system module 190 of FIG. 1 mayuse a method similar to method 800 described further below withreference to FIG. 8. If the user is not authorized to execute themethod, appropriate action may be taken 708, such as returning anotification that the user is not authorized to access the service or analternative service may be provided (e.g., view a file rather than edita file). If the user is authorized to execute the method, the metadataobject may be created in any suitable manner.

For example, the user may want to write code to load a new metadatapackage (e.g., family of related object). In one case, the user mayenter:

Using Microsoft.Office.Server.ApplicationRegistry.Administration;

// package URL

Uri packageUri = new Uri (“file://c/bla”);

// create a new system object

System new system = ApplicationRegistry.LoadFromPackage(packageUri);

When the new system is created using the .LoadFromPackage( ) method, anaccess check of operation 704 above may be performed to verify that therequesting user has the load from package (or execute) right associatedwith its user identifier in the ACE associated with the load frompackage method. In some cases the execute right may not be useful unlessit is also accompanied with an edit right. For example, the method maybe executed, but the results of the execution (e.g., a new metadataobject) may not be imported if the right to edit an object is not alsoauthorized. When the package is loaded, the child metadata objects(e.g., entities, methods, and the like) may be created with default ACLsthat mirror the original parent ACL. In some cases, all metadata objectsmay have a load from package(method) to allow packages to be authored atany level in the metadata object hierarchy.

If the parent object or any object in the package does not have anassociated ACL, the security parameters of the object may be created toset up security on a meta data object. The user may request 710 tocreate an ACL associated with a particular object. In response to therequest to edit the ACL (i.e., edit, as used herein, includes create,create child, delete, update, and the like), the service system module190 of FIG. 1 may determine 712 if the requesting user has access to therequested method object. For example, the service system module 190 ofFIG. 1 may use a method similar to method 800 described further belowwith reference to FIG. 8. If the user is not authorized to execute themethod, appropriate action may be taken 708. If the user is authorizedto execute the method, the ACL may be created 714 and populated withindicated user identifiers, rights associated with one or more useridentifiers, and the like.

For example, a user may want to write code to create or edit an ACL. Inone case, the user may enter:

Using Microsoft.Office.Server.ApplicationRegistry.Administration:

// obtain a handle to a metadata object

MethodInstance mi = MethodInstance.GetById(333);

//Read

SPGenericAcl acl = mi.GetAcl( );

// Set

mi.SetAcl(acl);

In the above example, the access check 712 may be performed in the.SetAcl( ) method on any metadata object. The access check may stipulatethat the requesting user of the SetAcl( ) method must have the setpermissions right in the ACL of the object (here method instance objectmi), or must have a set permissions right on the parent of the object.The ACL (here Acl) may be required to contain at least one ACE thatprovides some user identifier with the set permissions right to precludethe creation of an object that cannot be administered.

To populate the ACL and/or ACE of the object, the service module 190 mayprovide a user interface to facilitate location and entry of useridentifiers, rights, and the like. Examples of user interface displaysare illustrated in FIGS. 9-12. Although it is to be appreciated that anysuitable user interface and associated controls may be provided to theuser to facilitate editing objects and associated metadata values.

FIG. 9 illustrates an administration user interface 900 foradministering to a metadata object of the type 902 of entity. Thesecurity parameters of the object may be accessed by selecting thesecurity button 904, although it is to be appreciated that the securityparameters may be accessible directly in the administration userinterface display or through any suitable user interface control. If thecurrent user is not authorized to modify the security (e.g., does nothave set permission rights) on the metadata object and/or its parentmetadata object, then the security button may be disabled, grayed out,not provided, and the like.

In response to selection of the security button 904, the service module190 may display the manage permission interface, such as the managepermission interface 1000 illustrated in FIG. 10. The manage permissionsinterface may represent the ACL for the object that referred the user tothe interface page. In the interface 1000, each row 1004 may representan ACE. In a newly instantiated object, the list of ACEs may be null. Tocreate more authorized users for an object and their associated right,the permissions page 1000 may make a new user entry directly availableor may allow entry of new user identifiers to be accessed through anysuitable interface control, such as add users button 1002. Othersuitable interface controls may be provided which allow removal of usersfrom an ACE, such as remove users button 1006, modify permissions ofselected users button 1008, and/or any other suitable interface controlto allow a user to access, modify, and/or maintain an object.

In response to selection of the new users button 1002, the servicemodule 190 may display the add users interface, such as the add usersinterface 1100 shown in FIG. 11. The user may provide user identifiersthrough any suitable control. For example, as shown in FIG. 11, the usermay enter user identifiers into the users text box 1102 and/or byselecting discoverable user identifiers through the browse button 1104.The rights associated with the indicated one or more users may beprovided in any suitable manner. For example, upon entry of a useridentifier, default rights may be associated with the user identifierunless modified by the user. In another example, the add user interfacemay provide a list or other selection of available rights which may beselected or indicated in any suitable manner. The interface of FIG. 11illustrates available rights 1106 with associated check box controls1108.

In response to selection of the modify permissions button 1108 of FIG.11, the service module 190 may display the modify permissions usersinterface, such as the modify permission user interface 1300 displayedin FIG. 13. The user may select one or more users in the user interfaceof FIG. 11 and the modify permissions interface may allow permission forthose selected users to be modified. In another example, a modifypermissions page may allow selection or entry of an existing or newauthorized user of the object and allow permissions to be modifiedand/or created. As shown in the example user interface of FIG. 13, themodify permission interface may display the user identifier 1302 for theassociated object. The user interface may also display the associatedpermissions for the displayed users and/or the available options thatmay be selected for that user. For example, with reference to FIG. 13,the available permission options 1304 for the associated object andassociated user 1302 are displayed with an associated control, such asthe check box 1306, which may indicate and allow manipulation of thepermission as selected (e.g., checked) or prohibited (e.g., notchecked). By manipulating the associated control (e.g., the check boxes1306), the user may select and/or deselect available permissions. It isto be appreciated that any suitable user control interface may beprovided such a list boxes, text boxes, radio buttons, and the like.

In some cases, selection of a particular right to be associated with auser identifier may cause other rights to be associated with the useridentifier for that or other objects, may modify the role of the useridentifier, and the like. For example, if in the process of selectingrights for a new user, the set or manage permission right is selected,the new user may become a delegated administrator for the object and allobjects under this object. That is, the admin ACE may be propagatedautomatically down through the object hierarchy tree.

In some cases a user may wish to edit the security informationassociated with a metadata object and propagate this informationdownwards (if not done automatically) on all child metadata objects. Auser, such as a developer, may request 716 to edit the ACL of a parentobject. The user may request 718 to propagate the security informationof the (modified) parent object down to all or any indicated childobjects of the parent object. In response to the request to execute amethod (e.g., set and propagate an object), the service system module190 of FIG. 1 may determine 720 if the requesting user has access to therequested method. For example, the service system module 190 of FIG. 1may use a method similar to method 800 described further below withreference to FIG. 8. If the user is not authorized to execute themethod, appropriate action may be taken 708. If the user is authorizedto execute the method, the ACL may be modified 722 and then propagateddown to the appropriate children of the parent in any suitable manner.

For example, the user may enter code such as:

Using Microsoft.Office.Serve4r.ApplicationRegistry.Administration;

//obtain a handle to a metadata object

MethodInstance mi = MethodInstance.GetById(333);

//Read

SPGenericAcl acl = mi.GetAcl( );

//Set

mi.SetAclAndPropagate(acl);

In the example above, the access check 720 may be performed in responseto execution of the .SetAclAndPropagateo method on the object. Theaccess check may stipulate that the requesting user must have the setpermissions right on the object or the object's parent. The ACL may berequired to contain at least one ACE that provides some user identifierwith the set rights permission to preclude the creation of an objectthat cannot be administered. In the example code above, the ACL ispropagated to every child object of the given object automatically. Inthe example above, execution of editing the ACL for each child objectmay be automatically authorized since child objects' ACLs may be set ifthe user has set permission rights in the parent object.

In some cases a user may wish to edit the security informationassociated with a metadata object. A user, such as a developer, mayrequest 724 to edit the ACL of a parent object. In response to therequest to execute a method (e.g., modify an object), the service systemmodule 190 of FIG. 1 may determine 726 if the requesting user has accessto the requested method. For example, the service system module 190 ofFIG. 1 may use a method similar to method 800 described further belowwith reference to FIG. 8. If the user is not authorized to execute themethod, appropriate action may be taken 708. If the user is authorizedto execute the method, the ACL may be modified 728 in any suitablemanner.

For example, the user may enter code such as:

Using Microsoft.Office,Server.ApplicationRegistry.Administration;

// obtain a handle to the MethodInstance in some manner

MethodInstance mi = null;

//get Acl

SPGenericAcl acl = mi.GetAcl( ); 33/53

Acl.Clear;

//create an Ace

SPGenericRight rights = new SPGenericRights( );

SPBasePermissions perms = BdcRightsMapper.MapToWss.Execute)

Rights.GrantRightsMask = perms;

String providerName = ProviderPickerControl.TextBox( );

String principalName = UserpickerControl.TextBox( );

SPGenericAce ace =

new SPGenericAce(providerName +“\”+principalName, rights);

//add Ace and set Acl

Acl.Add(ace);

//will take time to propagate change to runtime OM

mi.SetAcl(acl);

The ACL Object Model (“OM”) may be Windows® SharePoint Services™ (WSS)or any other appropriate web infrastructure. The OM may provide basicauthentication, persistence, infrastructural and/or other securityservices to the enterprise system components. As shown in the aboveexample, the OM may provide default security values, such as rights,which may be referenced and implemented by the ACL and/or ACE. Inresponse to setting the ACL, the security change may be substantiallyimmediately changed within the context of the OM of the enterprisesystem. However, since metadata objects may be cached by a runtime OM,there may be a time lag before the changed ACL is observed on allcomponents by the runtime OM.

Although the above example illustrates editing security parameters of anobject, any parameter, feature, setting, and the like may be modified,such as the identifier of the object, an instance of an object, and thelike. As noted above, editing includes modifying, updating, creating,deleting functions, and the like. As shown in FIG. 7, a user may request742 to edit an object. In response to the request to edit an object(e.g., a request to execute a method), the service system module 190 ofFIG. 1 may determine 744 if the requesting user has access to therequested method. For example, the service system module 190 of FIG. 1may use a method similar to method 800 described further below withreference to FIG. 8. If the user is not authorized to execute themethod, appropriate action may be taken 708. If the user is authorizedto execute the method, the object may be modified 746 in any suitablemanner.

In one example, a user may desire to write code to update an Entity'sname, create a new object identifier for the Entity, and then delete theSystem that contains the Entity object.

For example, the user may enter code such as:

Using Microsoft.Office.Server.ApplicationRegistry.Administration;

//get the Entity object

Entity poorlyNamedEntity = Entity.GetById(321);

PoorlyNamedEntity.Name = ‘amuch better name’

poorlyNamedEntity.Update( ); //access check 1

PoorlyNamedEntity.Identifiers.Create(“newIdName”); //access check 2

System uglyUnwantedSystem =

poorlyNamedEntity.System.Delete ( ); //access check 3

As shown in the example above, more than one access check may beperformed by the data store service system 160 of FIG. 1. In the exampleabove, three access checks may be performed in response to the requestto create the child object, delete the system object, and updating theACL of an object. However, it is to be appreciated that one or moreaccess checks may be performed at the same time. For example, in theexample above, each of the executed methods may require an edit right toa metadata object (e.g., create, delete, update), and thus, the threeaccess checks may be performed with a single access data check for thatright, however, it is to be appreciated that the edit right may bedifferent for the identifier user for the three different objects edited(e.g., the child object, the entity object, and the system object, andthus may need a separate access check for each object.

A user may wish to alter some metadata stored in the metadata store 180of FIG. 1. For example, a user may wish to alter the connection stringon an application, e.g., the connection information 204 associated witha system object, as shown in the metadata store of FIG. 2. In some casesthe service system 190 of FIG. 1 may provide an edit object page tofacilitate editing the object metadata. An example edit applicationobject page 1200 is shown in FIG. 12. When the edit application page ispresented to the user, an access check may be performed against the ACLassociated with the application object to verify that the identifieduser has the proper edit right. If the access check fails, the user maybe denied access to the object page, such as object page 1200, oralternatively, the object page may be displayed, but the edit functionof fields within the page may be turned off, e.g., a read-only view ofthe page.

As noted above, an object may have an associated ACL which controlswhich people have which permissions. In some cases, an object may becreated with a default ACL identical to its parent object. In the caseof a system object at the top of the hierarchy, the default may createadministrative rights in the creator of the object. However, there mayexist additional or some subset of rights, such as right to edit anobject, right to execute an object (which may result in an applicationinvocation), asymmetric rights, and the like. One example of anasymmetric right is the right to change the rights of the object, whichmay be included in the administrative rights in the object. The right tochange the rights in an object may be delegated to another user.Specifically, the person having the right to change the rights in anobject may assign another user to additionally or alternatively have theright to change the rights in the object.

In some cases, the user may wish to delegate the administrative rightsof that object and all underlying (child) objects to another user. Auser, such as a developer, may request 730 to delegate administrativerights of an object and its children. In response to the request toexecute a method (e.g., set and propagate an object), the service systemmodule 190 of FIG. 1 may determine 732 if the requesting user has accessto the requested method. For example, the service system module 190 ofFIG. 1 may use a method similar to method 800 described further belowwith reference to FIG. 8. If the user is not authorized to execute themethod, appropriate action may be taken 708. If the user is authorizedto execute the method, the ACE may be added and the ACL may be modified734 and then propagated down to the appropriate children of the parentin any suitable manner.

For example, the user may enter code such as:

Using Microsoft.Office.Server.ApplicationRegistry.Adminstration;

//obtain handle to a metadata object

MethodInstance mi = MethodInstance.GetById(333);

//Read

SPGenericAcl acl = mi.GetAcl( );

//create an Ace

SPGenericRight rights = new SPGenericRights( );

SPBasePermissions perms =

BdcRightsMapper.MapToWss(BdcRights.SetPermissions)

Rights.GrantRightsMask = perms;

String newAdmin = “newAdminDude”;

SPGenericAce ace =

New SPGenericAce(newAdmin,rights);

//add Ace and set Acl

Acl.add(ace);

//may take time to propagate change to runtime OM

mi.SetAclandPropagate(acl);

As a result of the new ACE in the ACL for the object, the useridentified with ‘newAdminDude’ has the right to set permissions on theobject. In this manner, the ‘newAdminDude’ can remove the old admin'sright to set permissions in that object or any lower object. However, ifthe old admin retains a ‘set permissions’ right in a parent object, thenthe old admin may be considered to only have delegated administration ofthe child objects of that parent object. In this manner, the old admincan regain any rights given to ‘newAdminDude’ since the old admin hasset permission rights in a parent of each object currently delegated tothe ‘newAdminDude’.

In some cases, the administrator of the metadata store (e.g., having setpermission rights on all objects within the metadata store) may want toallow another user to have administrative rights in particular types ofobjects. For example, the administrator may wish another user to haveadministrative rights in any Entity object but not the SystemInstanceobject to which the entities belong. Accordingly, the administrator maychange MethodInstance execute privileges, but not alter the connectionstring on the SystemInstance, for example. A user, such as a developer,may request 736 to partially delegate administration of an object andits children. In response to the request to execute a method (e.g., setand propagate an object), the service system module 190 of FIG. 1 maydetermine 738 if the requesting user has access to the requested method.For example, the service system module 190 of FIG. 1 may use a method800 similar to that described further below with reference to FIG. 8. Ifthe user is not authorized to execute the method, appropriate action maybe taken 708. If the user is authorized to execute the method, the ACEmay be added and the ACL may be modified 740 and then propagated down tothe appropriate children of the parent in any suitable manner. Forexample, the user may enter code such as:

Using Microsoft.Office.Server.ApplicationRegistry.Administration;

//obtain a handle to a metadata object

System s = System.GetById(333);

//Read

SPGenericAcl acl = s.GetAcl( );

//create an Ace

SPGenericRight rights = new SPGenericRights( );

SPBasePermissions perms =

BdcRightsMapper.MapToWss(BdcRights.SetPermissions);

Rights.GrantRightsMask = perms;

StringNewAdmin = “newAdminDude’;

SPGenericAce ace = new SPGenericAce(newAdmin,rights);

//add Ace and set Acl

Acl.Add(ace);

//may take time to propagate change to runtime OM

s.SetAclAndPropagate(acl);

//Get Acl on SystemInstance and remove newAdmin Ace

For each(SystemInstance si in System.GetSystemInstances( ))

{

SPGenericAcl acl = si.GetAcl( );

Acl.Remove(ace);

}

As shown above, there may be cases where automatic inheritance of an ACLfrom parents to children may be avoided and/or desired. Thus, it is tobe appreciated that automatic inheritance may occur only in some cases,and other cases may require copying or explicit propagation to propagatethe ACL down to child objects.

FIG. 8 illustrates an example method 800 of checking access to anobject. As noted above, the security may be surfaced by injecting accesscheck calls for various rights at key methods on a securable object. Tocheck access to an object, the request may be received 802. The requestor other aspects of the communication may be parsed to determine 804 theuser identifier for the requesting user. It is to be appreciated, that arequest may be by proxy of another user by providing a user identifierfor use with authorization and/or authentication. The requesting usermay be authenticated 806 in any suitable manner, i.e., the identity ofthe user may be verified. In some cases, the portal 170 and/or the datastore service system may authenticate a user before any request is made.Thus, it is to be appreciated that any of the described steps and/oroperations may be performed in any suitable order appropriate to theapplication and environment.

The desired services to be accessed may be determined 808 from the userrequest, such as user request 162 of FIG. 1. Any suitable portion of theenterprise system may determine the desired service to be accessed, suchas the service system module 190 of FIG. 1 or an authorization module(not shown) of the data store services system 160. The rights requiredto access the desired service may be determined 810 in any suitablemanner. For example, the metadata store may maintain a database ofrights, such as a mapping of methods or services and the requiredrights, or as noted above, the required rights to access the desiredservice may be associated within the service itself, e.g., whenimplementing a method object, the method object may provide the rightsrequired for the service.

The object to be accessed may be determined 812 from the request. Forexample, the service request may be to edit an object, view an object,execute an object, and the like. The desired object may be indicated inany suitable manner such as with an object name, object type, objectidentifier, and the like. The ACL for the desired object may beretrieved 814 and the associated ACE(s) of the ACL may be retrieved 816.As noted above in one example, the ACL may be retrieved from the objectitself, if it is classified as an individually securable object, or fromanother object, such as a nearest individually securable object, if theobject is classified as an access securable object. If the ACL isretrieved from another object, any suitable method may be used toretrieve the ACL including determining the nearest individuallysecurable object.

The ACE may be examined 818, to determine if the user identifier isprovided as an authorized user, e.g., is included in the list of useridentifiers in the ACE. If not, appropriate action may be taken 820. Anynumber and combination of suitable appropriate actions may be takenincluding denying the user access to the requested service, sending amessage to the user that access is denied, notifying an administrativeuser of denied access, logging the denied access in a log data storewhich may be stored in the storage 138 of FIG. 1, and the like.

If the user is listed within the ACE, the rights associated with theuser identifier may be compared 822 to the required rights determined inoperation 810 above. If the required rights are not associated with theuser identifier, appropriate action may be taken 820. Any of the abovenoted appropriate actions may be taken. Moreover, if the user has somerights in the object, but not the required rights for the desiredaccess, the data store service system may automatically choose anappropriate authorized service rather than the requested service forwhich the user does have associated rights. For example, a user mayrequest to edit an object, but may not have edit rights. In response,the data store service system may check the ACE if the user identifierfor the requesting user has an associated right to view the object. Theassociated right may then become part of the generated request ofservice to the application, such as request 164 described further below.

If the right or associated right(s) are indicated in the ACE, otherrestriction on access may be verified 824. For example, secure access toa service may be based on any context in addition to or alternative tothe user identity provided above. For example, access may be based upona verification of a feature in an application, a location within a website, time of day and/or date of access, connection limitations on theuser connection to the enterprise system, and the like. If the otherrestrictions are not verified, appropriate action may be taken 820.

If the user is authorized, the data store service system may generate826 a request for the indicated service of the appropriate application.The request may be generated in any suitable manner. The request fromthe user, such as request 162 of FIG. 1 may be repeated or appropriatelymodified (e.g., formatted, extended, and the like) to send to theapplication 150 of FIG. 1. In another example, the data store servicesystem may retrieve appropriate request information regarding thedesired service from the metadata store 180 of FIG. 1 based on theobject of the service and/or any parent objects of the service object.For example, with reference to FIG. 2, the data store service system mayuse the entity identifier 224, parameter list 226, or any other suitableinformation to generate the complex request 164 suitable for theapplication 150 to provide the requested service.

The application may desire to authenticate and/or authorize the datastore service system. As noted above the authentication and/orauthorization may be done prior to the request or as a part of executingthe request. As shown in FIG. 8, the data store service system mayprovide to the application the appropriate account, connection,identification, credentials, and the like to the application, any ofwhich may be retrieved from the metadata store 180 of FIG. 1. Forexample, the data store service system may access the applicationthrough a user account or service account with authentication and/orauthorization information unique to the data store service system whichmay be retrieved from the metadata store 180 based upon the objectidentifier and the information associated with that object and any ofits parent objects in the metadata store. The data store service systemmay be capable of signing on and being authorized by one or moresecurity systems including server process accounts which have nocredential, WINDOWS® credentials from single sign-on where the datastore service system may impersonate a WINDOWS® user with its owncredentials of a single sign-on (SSO) individual account and performsWINDOWS® authentication, and the like.

By centralizing user authorization, administration of the enterprisesystem may be simplified by maintaining only one or more user accountswith each of the applications 150 of FIG. 1, of which the data storeservice system maintains an account, user credentials, and the like. Asnoted above, the connection and/or security information may be differentfrom the connection and/or security information of the requesting user.The data store service may maintain and retrieve the authentication,connection, authorization information in the metadata store 180, asdiscussed above. Moreover, if the data store service system isprocessing one or more requests for services from the same application,those requests may be pooled together through the same user thread,which may require only one account, connection, and the like.

The application may authenticate, verify authorization, and the like 830in any suitable manner based on the provided information from the datastore service information. To ensure that the data store service systemis authorized to access the requested service, the rights associatedwith the data store service system may be the same as or greater than(e.g., super-user) as compared to all of the rights allowed toidentified users in the object's ACL.

If the data store service system is authorized, the service may beaccessed 832. When the service is accessed, an indication of success maybe received 834 from the application. The indication of success may beany suitable indication of success, such as the results of an executedmethod, an indication that the service was successfully implemented,access to features of the application may be provided, and the like. Thedata store service system may provide 836 an indication of success tothe requesting user in any suitable manner.

In one example, a user may desire to write code to verify if the currentuser using his code (e.g., one or more of applications 150) isauthorized to execute a MethodInstance. The user may write:

Using Microsoft.Office.Server.ApplicationRegistry.MetadataModel;

//obtain a handle to the MethodInstance in some manner

MethodInstance mi = null;

//get the Acl

SPGenericAcl acl = mi.Getacl( );

//check for execute access

If (acl.AssertPermissions(BdcRightsMapper.MapToWss(BdcRights.Execute))

{

//allow user access to the MethodInstance object

}

Else

{

Throw new AccessDeniedException( );

}

Although the above example may be a bit contrived, since it is not atypical end user scenario, it illustrates example code that may beembedded in the data store service system Methodlnstance.Execute( ) codeto allow or deny a user access to a backend API or other application. Inthis example, WSS is checking where the user is that same as a useridentifier listed in one of the ACEs in the ACL for the given right(Execute in the example above). However, it is to be appreciated thatany suitable method or process may be used to verify authorization.

Although the examples of requests for service above of FIG. 7, andauthorization for access of FIG. 8 are discussed above using the objectsof the metadata store themselves, the method may be similarlyimplemented for a user, such as user 120 of FIG. 1 requesting servicesfrom the one or more applications 150. For example, with reference toFIG. 8, the request may be received 802 and information determined 804,808, 810, 812, 814 with reference to the objects of application 150stored in the metadata store. The associated ACL and ACE may beretrieved for the object associated with the requested service, andrights and user identity verified. As noted above, each object stored inthe metadata store is associated with and ACL which is associated withan ACE. The data store service system may then generate 826 a requestfor the services in response to an authorized request from the user, andprovide 828 its own authentication information to access the application150 for the service.

As shown in the examples above, the ACLs and ACEs associated with eachobject may be used within the creation and maintenance of other objectsin the data store service system. Specifically, some types of objects ofthe data store service system may be used to crate, edit, and/ormaintain objects of a back-end application. For example, as shown in theexample method 1400 of in FIG. 14, an object may be created 1402 for oneor more portions of a back-end application. As noted above, the objectsmay represent one or more of the hierarchy of objects such as a system,system instance, entity, method, parameter, parameter type, and thelike. The objects may be created in any suitable manner, such as thatdescribed above with respect to creating an object in operations 702-706and creating security in operations 710-714 of FIG. 7. The user devicemay request 1404 a service from a back end application of the enterprisesystem. The use request may be a simple, universal, unified and/orcommon request which may allow a common interface for the user across aplurality of back-end applications. As shown in the example of FIG. 1,the user request may be received by the enterprise system 130 throughany suitable communication connection and which may be processed througha portal 170. With reference to FIG. 14, the data store service systemmay determine 1406 the appropriate objects referenced by the request.The data store service system may then determine 1407 if the user isauthorized to access any one or all of the indicated objects in therequested manner. Although any suitable authorization process may beused, one suitable example is discussed above with respect to the method800 of FIG. 8. If the user is not authorized, the data store servicesystem may take 1408 appropriate action, which may include any one ormore of terminating the request, sending an error message to therequesting user, and the like. If the user is authorized, the data storeservice system may generate 1410 a request that is specifically tailoredfor interaction with the requested service of the appropriate back-endapplication of the enterprise system. For example, the informationmaintained within the objects may include the message format, parametersneeded, and the like which may be used to generate the message. The datastore service system may then use the tailored request to interact 1412with appropriate back-end application to access the service identifiedin the request from the user. For example, the data store service systemmay send the tailored request to the back-end application to access theappropriate service. The connection to the back-end application may bethrough a super-user account of application, and which may bepre-fabricated. The service results may be provided by the back-endapplication to the data store service system, which may tailor theresults in accordance with the specific request from the user (e.g.,data format, language, and the like), in accordance with the userpreferences (e.g., user preferred data formats, languages, and thelike), in accordance with user permissions (e.g., information may beculled, translated, or redacted as appropriate) which may occur if theapplication does not have the information fidelity required to fulfillthe specific user request and/or permission, and the like. the datastore service system may interact 141 with the user device such as tocommunicate status information, results of the request, and the like.

While the preferred embodiment of the invention has been illustrated anddescribed, it will be appreciated that various changes can be madetherein without departing from the spirit and scope of the invention.For example, as noted above, the enterprise system may separate theexecutable functionality existing in backend applications, and theseparation may be at differing levels of granularity. The separatedfunctions of the application may be registered in a catalog in the formof metadata objects. Once the executable functionality has beenregistered, the authorization information for each granular functionalobject may be associated with authorization information. One example ofan authorization right of an executable functionality may be the rightto ‘execute’ the portions of logic associated with the executablefunctionality, which may access and/or modify information of theapplication. In addition to authorizing execution of a functionality,the metadata store may additionally or alternatively facilitateauthorization of where (such as within a large portal application) theexecution can be done. Like the execution authorization, the location ofthe execution may be authorized on a feature by feature (or object byobject) basis. For example, although the above examples describe using adata store service system to access one or more applications, withobjects defined as systems, entities, and the like, it is to beappreciated that objects or access requests may refer to any suitablemethod, object, application, and the like. For example, an applicationfeature may allow creation of a user interface widget call Web Parts.Another feature of the application may allow creation of scopedsearchable/indexable spaces. The authorization information assoicatedwith an object in the metadta store may allow, that within the Web Partfeature, only sysem A's data may be displayed. Similarly, the metadataauthorization information may allow, within the Search fature, onlysystem B's customer entitiy data can be crawled. In this manner, anobject stored in the metadata store may refer to search objects, webpage connectivity and access, and the like. Similarly, although thesecure data store service system is implemented above with reference toobjects, such as XML objects, it is to be appreciated that lists, andother types of programming constructs may be used as suitable.

1. A method for authorizing a user comprising: a) receiving from a userdevice a first request for a service of an application; b) determining auser identifier associated with the user device; c) determining anaccess right required to access the service without accessing theapplication; d) determining if the user identifier is associated withthe access right; e) in response to a determination of the useridentifier being associated with the access right, generating a secondrequest for the service of the application, the second request beingdifferent from the first request; f) sending the second request to theapplication; g) accessing the application using one or more usercredentials different from one or more credentials of the user device.2. The method of claim 1, wherein determining if the user identifier isassociated with the access right includes accessing an object associatedwith the service, the object being stored in a data store.
 3. The methodof claim 2, wherein accessing an object includes accessing an accesscontrol list associated with the object.
 4. The method of claim 3,wherein the access control list is owned by the object.
 5. The method ofclaim 3, wherein accessing an access control list includes accessing anaccess control list of another object.
 6. The method of claim 5, furthercomprising determining the another object by determining a nearestancestor of the object owning an access control list.
 7. The method ofclaim 6, wherein the object is selected from a group comprising a systemobject, a system instance object, an entity object, a method object, aparameter object, and a parameter type object.
 8. The method of claim 7,further comprising organizing the group of a system object, a systeminstance object, an entity object, a method object, a parameter object,and a parameter type object as a hierarchy, and wherein determining anearest ancestor of the object includes based on the hierarchy,determining a higher level object associated with the object and owningan access control list.
 9. The method of claim 3, wherein accessing anobject includes accessing an access control entry associated with theaccess control list, the access control entry including at least oneauthorized user identifier associated with at least one authorized rightof access.
 10. The method of claim 9, wherein the at least oneauthorized right of access is selected from a group comprising a rightto edit, a right to view, and a right to execute.
 11. One or morecomputer readable media having stored thereon a data structurecomprising: a) a first data field containing data representing an objectidentifier, the object identifier indicating an available service of anapplication; b) a second data field, associated with the first datafield, containing data representing an access control list identifier;c) a third data field, associated with the second data field, containingdata representing an access control entry identifier; d) a fourth datafield, associated with the third data field, containing datarepresenting a user identifier associated with an authorized user of theapplication; and e) a fifth data field, associated with the third datafield, containing data representing a right identifier indicating anauthorized right of the authorized user to access the available service.12. The one or more computer readable media of claim 11, wherein theaccess control list identifier references an access control listapplication program interface for checking access rights of a user tothe application.
 13. The one or more computer readable media of claim11, wherein the access control entry identifier references an accesscontrol entry application program interface for verifying access rightsbased on the fourth and fifth data fields.
 14. The one or more computerreadable media of claim 11, wherein the object identifier identifies anobject having a type selected from a group comprising a system object, asystem instance object, an entity object, a method object, a parameterobject, and a parameter type object.
 15. One or more computer readablemedia containing computer readable instructions that, when implemented,perform a method comprising: a) associating a service identifier withconnection information, an authorized user identifier, and an accessright indicator of the authorized user identifier, wherein the serviceidentifier is associated with a service of at least one of a pluralityof available applications providing services; b) receiving a request forthe service from a user device; c) verifying that a user identifierassociated with the user device matches the authorized user identifierwithout accessing the at least one of the plurality of availableapplications; d) based on the access right indicator, verifying that therequest for the service is allowed by the authorized right indicatorwithout accessing the at least one of the plurality of availableapplications; e) if the user identifier and the request are verified,accessing the at least one of the plurality of available applicationsusing credentials different from user credentials of the user device;and f) requesting the service from the at least one of the plurality ofavailable applications.
 16. The one or more computer readable media ofclaim 15, wherein associating a service identifier with an authorizeduser identifier and an access right indicator of the authorized useridentifier includes associating the service identifier with an accesscontrol list and associating the access control list with an accesscontrol entry, the access control entry associating the authorized useridentifier and the access right indicator.
 17. The one or more computerreadable media of claim 16, wherein associating the service identifierwith an access control list includes creating a service objectcontaining the access control list.
 18. The one or more computerreadable media of claim 16, wherein associating the service identifierwith an access control list includes associating the service identifierwith an application program interface for discovering a nearest ancestorobject of the service identifier that contains the access control list.19. The one or more computer readable media of claim 18, whereindiscovering a nearest ancestor object includes walking up apredetermined object hierarchy associated with the service identifierand determining a nearest higher level object containing an accesscontrol list.
 20. The one or more computer readable media of claim 15,further comprising associating the authorized user identifier and accessright indicator with a child service indicator associated to the serviceindicator in accordance with a service hierarchy.